home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / tls / tls018d.ltr < prev    next >
Text File  |  1994-09-02  |  7KB  |  160 lines
  1. Subj: TLS018d - monitor and trace utilities
  2.  
  3. Changes 22 Feb 94 to revision d:
  4.     new version of trace:
  5.         - supports forke and exec.  Can trace forked children
  6.           and exec'd programs
  7.  
  8. Changes 13 May 93 to revision c:
  9.     remove gbcw
  10.                 - This version was too fragile; withdrawn.
  11.         - no longer being maintained.
  12.  
  13.     new version of trace:
  14.         - supports shared libraries
  15.         - intercepts sigprocmask and sigaction calls and
  16.           prevents them from blocking SIGTRAP
  17.         - SIGINT now terminates trace as claimed.
  18.         - if traced process forks, forked child no
  19.           longer dies with SIGTRAP
  20.  
  21. Changes revision "b"  17 Mar 93: new version of bcw handles larger number
  22. of buffer headers, displays buffer cache aging information]
  23.  
  24. ---------------
  25.  
  26. This TLS contains some interesting utilities and debug tools.
  27.  
  28.    memhog - displays utilization of cpu, memory, and i/o
  29.    bcw - buffer cache watch: display info about buffer cache
  30.    showreg - show regions attached to a process
  31.    trace - trace system calls
  32.  
  33. There are three directories:
  34. bin:
  35.     stripped binaries, compiled with static libraries
  36. man:
  37.     man pages for the commands in bin.
  38. cat:   
  39.         formatted man pages (nroff)
  40.  
  41. This is just a plain tar file.  You can decide where to install
  42. the bits and pieces.
  43.  
  44. Note that all programs except trace must be able to read /unix and
  45. /dev/kmem.  The safest way to set this up is to make /unix and /dev/kmem
  46. group mem, group readable, and make these programs sgid mem.  As
  47. shipped, they can only be run by root.
  48.  
  49. Also note that trace will not work on binaries stored on NFS filesystems
  50. unless you are running 3.2v4 (on the NFS client side).
  51.  
  52. Comments are welcome.  The author is Tom Kelly, tom@sco.com.
  53. See below for some useful comments from Jim Sullivan.
  54.  
  55. Dion L. Johnson
  56. SCO Product Manager - Development Systems  400 Encinal St. Santa Cruz, CA 95061
  57. dionj@sco.com   Compuserve: 71712,3301   FAX: 408-427-5417  Voice: 408-427-7565
  58. ===============================================================================
  59. Output from bcw:
  60.  
  61. buffers: 200 (200 K) hash slots:  64 pbufs:  20
  62. lread    0 bread    0 (hit 100) lwrite    0 bwrite    0 (hit 100) w:r   0
  63. in-cache 198 slots used  63 longest   8 shortest   1 async  0
  64. median chain:   3
  65. >120s:    0 >60s:    0 >30s:  159 >10s:   35 >5s:    0 >1s:    4 >0s:    0
  66. Busy   0 !Done   0 Want   0 Async   0 DelWri   9 Stale   0 Remote   0
  67. 132131 432321212142453334334733444231358545542244333155433523321
  68.  
  69. Explanations:
  70.  
  71. >>buffers: 200 (200 K) hash slots:  64 pbufs:  20
  72.  
  73. Buffers is the value of NBUFS, hash slots is NHBUFS and pbufs is NPBUFS
  74.  
  75. >>lread    x bread    y (hit 100) lwrite    z bwrite    v (hit 100) w:r   u
  76.  
  77. lread, bread, lwrite and bwrite are the same as is documented in the SAG
  78. for sar -b.  What this says is that during the last sample period, there
  79. were x logical reads (user programs read data that was present in the
  80. buffer cache, no disk access was required), y block reads (data was not
  81. found in the buffer cache, so we actually had to scheduled a read from the
  82. disk and wait for it to complete before we returned to the program),
  83. z logical writes (where the user programs have written data, but it is
  84. just being buffered in the cache) and v block writes (we've written v
  85. dirty buffers to the disk).  The ``hit'' number are the percentage of
  86. operations that went to cache instead of disk (lread/(lread+bread)) and
  87. lwrite/(lwrite+bwrite).  The w:r is the ratio of write to reads.
  88.  
  89. >>in-cache 198 slots used  63 longest   8 shortest   1 async  0
  90. >>median chain:   3
  91.  
  92. >>132131 432321212142453334334733444231358545542244333155433523321
  93.  
  94. Disk buffers are either in the cache or on the free list.  The in-cache
  95. number is approximately the number of buffers in the cache (approximate
  96. because it gets the number by adding up the lengths of the chains, but
  97. they could change during the summation period).  If you had 600 buffers
  98. allocated and the in-cache number is consistantly less than 600, you
  99. have too many buffers allocated and you can use that memory elsewhere.
  100.  
  101. slots-used is the number of hash buckets that actually have real buffers
  102. attached to them.  If you look at the final line (the row of numbers)
  103. you will notice that there is a single blank space.  In our example,
  104. there are 64 NHUFS (hash buckets) and one is not in use, at this time.
  105. slots-used is NHUFS-1=63!  If this number if significant less than NHBUFS,
  106. there may be a problem, since the disk buffers are not being distributed
  107. equally across the hash buckets.  We'll discuss this in a second.
  108.  
  109. longest and shortest represent the length of the longest and shortest
  110. hash chains.  The final line is the actual lengths of each hash chains.
  111. median chain is the median (the value in an ordered set of values below
  112. and above which there is an equal number of values, websters) of the
  113. hash chains.  Ideally, this number should be small (<=4).  Remember that
  114. when we do a read or a write, we first check the buffer cache to see if
  115. the data block is already in cache.  Each check consists of a comparison
  116. of the block addresses.  The algorithm looks something like this:
  117.  
  118.     calculate hash bucket (using block address)
  119.     ptr = start of hash chain
  120.     while( ptr.baddr != block address )
  121.         ptr = ptr.next
  122.  
  123. Ideally, you want to whip through this loop, because if the data block is
  124. not in the cache, you'll have to read it in.  If you spend too much time
  125. in this loop, then the buffer cache starts to get in the road.  This is
  126. why you should always increase NHBUFS to approximately NBUFS/4 when you
  127. increase NBUFS.  Our process to automatically determine NBUFS on startup
  128. is flawed in that it will not increase NHBUFS accordingly.  I suspect
  129. there are a large number of systems out there with NHBUFS=64 and NBUFS
  130. being dynamically determined at startup.  I've seen sites with NBUFS in
  131. excess of 2000, but NHBUFS still at 64.  Needless to say, disk performance
  132. is terrible.
  133.  
  134. If the last line has an asterisk in it, it means that the length of the
  135. hash chain is greater than 10, which obviously could be a bad thing.
  136. Many *'s means the buffer cache is not performing to its potential.
  137.  
  138.  
  139. >>>120s:    0 >60s:    0 >30s:  159 >10s:   35 >5s:    0 >1s:    4 >0s:    0
  140.  
  141. This is aging data.  Buffers get re-used depending on their age, with older
  142. buffers going first.  The idea is that if you are reading a particular
  143. buffer regularly, then re-using that buffer is bad.  You should re-use a
  144. buffer that is not used regularly.  The numbers presented here should
  145. add up to the in-cache number.  In my example, I have 159 buffers that
  146. have not been touched (read or written) in the last 30 seconds.  The idea
  147. came from the net, where there was a request to have this type of
  148. information.  With this info, you can get an idea of the total number of
  149. buffers you'd need, in general.  Remember that buffers do not get recycled
  150. until they are needed, so regularly used buffers (representing
  151. commonly read/written data) are never/rarely recycled.  If you have a
  152. large number of buffers in the 120 seconds field, then you MIGHT be able
  153. to reduce the total NBUFS number by that amount.
  154.  
  155. >>Busy   0 !Done   0 Want   0 Async   0 DelWri   9 Stale   0 Remote   0
  156.  
  157. This line represents that status of the buffers, and corresponds to the
  158. actual states that a buffer can be in. 
  159. ---------------
  160.